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Token Authentication System 

An embodiment of the present invention includes a protocol for generating One Time 
Passwords ("OTPs") that can be used to authenticate a user. The OTPs are generated by a token, 
which can be a physical device that includes mechanisms to prevent the unauthorized 
modification or disclosure of the software and information that it contains, and to help ensure its 
proper functioning. 

An embodiment of this protocol can be sequence based, and can be two-factor, e.g., based 
upon something the user knows (such as a Personal Identification Number and a physical device 
that the user posesses (e.g., a token.) 



The protocol for generating the OTPs can be based upon a counter, e.g., a monotonically 
increasing number based, for example, on the number of times a OTP has been requested from 
the token. The value of the OTP can be displayed on a token, and can be easily read and entered 
by the user, e.g., via a keyboard coupled to a computer that is in turn coupled to a network. The 
OTP can be transportable over the RADIUS system. 

An embodiment of the protocol in accordance with the present invention can based on an 
increasing counter value and a static symmetric key known only to the token and an v 
authentication service (the "strong auth" service.) An OTP value can be created using the 
HMAC-SHA1 algorithm as defined in RFC 2104. This hashed MAC algorithm has the strength 
of SHA-1, but allows the addition of a secret during the calculation of the output. 

The output of the HMAC-SHA1 calculation is 160 bits. However, this value can be 
truncated to a length that can be easily entered by a user. Thus, 

OTP = Truncate(HMAC-SHAl (Count, Secret)) 

Both the client and authentication server can calculate the OTP value. If the value received by 
the server matches the value calculated by the server, then the user can be said to be 
authenticated. Once an authentication occurs at the server, the server increments the counter 
value by one. 

Although the servers counter value can be incremented only after a successful OTP 
authentication, the counter on the token can be incremented every time the button is pushed. 
Because of this, the counter values on the server and on the token will be often out of 
synchronization. Indeed, there is a good chance that the token will always be out of 
synchronization with the server given the user environment (e.g., the user pushes the button 
unnecessarily, button is pushed accidentally, user mistypes the OTP, etc.) 

Because the server's counter will only increment when a valid OTP is presented, the 
server's counter value on the token is expected to always be less than the counter value on token. 
The key to ^synchronization is to ensure it's not a burden to either the user or the enterprise IT 
department. 
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Synchronization of counters is in this scenario can be achieved by having the server 
calculate the next n OTP values and determine if there is a match, where n is an integer. If we 
assume that the difference between the count at the token and the count at the server is 50, then 
depending on the implementation of the strong auth server, the server would at most have to 
calculate the next 50 OTP values, thus, for example, if the correct OTP is found at the «+72 
value, then the server can authenticate the user and then increment the counter by 12. 

It is important to carefully choose a value for n that can be easily calculated by the server. 
There should be upper bounds to ensure the server doesn't check OTP values forever, thereby 
succumbing to a Denial of Service attack. 

Truncating the HMAC-SHA1 value to a 6 character value could make a brute force attack easy 
to mount, especially if only numeric digits are used. Because of this, such attacks can be 
detected and stopped at the strong auth server. Each time the server calculates an OTP that does 
not validate, it should record this and implement measures to prevent being swamped, e.g., at 
some point, turn away future requests for validation from the same source. Alternatively, the user 
can be forced to wait for a longer period of time between validation attempts. 

Once a user is locked out, the user can be to "self unlock" by providing a web interface 
that would require the user, for example, to enter multiple OTP in a sequence, thus proving thfey 
have the token. 

Once the shared secret has been combined with the counter, a 160 bit (20-byte) HMAC- 
SHA1 result can be obtained. In one embodiment, at most four bytes of this information for our 
OTP. The HMAC RFC ( RFC 2104 - HMAC: Keyed-Hashing for Message Authentication ) 
further warns that we should use at least half the HMAC result in Section 5 Truncated Output: 

Applications of HMAC can choose to truncate the output of HMAC by 
outputting the t leftmost bits of the HMAC computation ... We recommend that 
the output length t be not less than half the length of the hash output ... and not 
less than 80 bits (a suitable lower bound on the number of bits that need to be 
predicted by an attacker). 

Thus, another way is needed to choose only four or fewer bytes of the HMAC result in a way 
that will not weaken either HMAC or SHA1 . In one Dynamic offset truncation, described below, 
can be used. 

Dynamic offset truncation. 

The purpose of this technique is to extract a four byte dynamic binary code from an 
HMAC-SHA1 result while still keeping most of the cryptographic strength of the MAC. 

1 . Take the last byte (byte 1 9) 

2. Mask off the low order four bits as the offset value 

3. use the offset value to index into the bytes of the HMAC-SHA1 result. 

4. return the following four bytes as the dynamic binary code. 
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The following code example describes the extraction of a dynamic binary code given that 
hmac_resuit is a byte array with the HMAC-SHA1 result: 

int offset = hmac_result [19] & Oxf ; 

int bin_code = (hmac_result [of f set] & 0x7f) << 24 

| (hmac_result [of f set+1] & Oxff) << 16 

j (hmac_result [of f set+2] & Oxff) << 8 

| (hmac_result [of f set+3] & Oxff) ; 

The following is an example of using this technique: 

SHA-1 Hash 
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1 . The last byte (byte 19) has the hex value 0x5a. 

2. The value of the lower four bits is Oxa (the offset value). 

3. The offset value is byte 10 (Oxa). 

4. The value of the four bytes starting at byte 10 is 0x50ef7fl9 which is the 
dynamic binary code. 

We treat the dynamic binary code as a 31 bit, unsigned, big-endian integer; the first byte is 
masked with a 0x7f. 

The One Time Password for a given secret and moving factor can vary based on three 
parameters: Encoding Base, Code Digits, and Has Checksum. With 10 as an Encoding Base, 
7 Code Digits and Has Checksum set to TRUE, we continue with the above example: 

• The hex value 0x50ef7fl9 converts to 1357872921 base 10. 

• The last 7 digits are 7872921 

• The credit card checksum of the code digits calculates 7 as the checksum. 
10- ((5 + 8 + 5 + 2 + 9 + 2 + 2) mod 10) = 10 - (33 mod 10) = 10-3 =7 

• Yielding the following OTP: 78729217 

The following is the Glossary: 

Checksum Digit - Result of applying the Credit-Card checksum algorithm to 
the Code Digits. This digit is optional. This check should catch any 
single transposition or any single character mistyped. 

Code Digits - This parameter indicates is the number of digits to be obtained 
from the binary code. We calculate the Code Digits by converting the 
Binary Code to the Encoding Base, zero padding to be at least Code 
Digits, and taking the right hand (low order) digits. With ten as an 
Encoding Base, no more than nine Code Digits can be supported by 
the 31 -bit Binary Code. 

Credit Card checksum algorithm - This checksum algorithm has the 

advantage that it will catch any single mistyped digit, or any single 
adjacent transposition of two digits. These are the most common types 
of user errors. 
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Encoding Base - This parameter indicates what base to use for the password. 
Base 10 is the preferred base because it can be entered in a numeric pad. 

Has Checksum Digit - This boolean parameter indicates if a checksum digit 
should be added to create the OTP. If there is no checksum digit, just 
the Code Digits are used as the OTP. If there is a checksum digit, it is 
calculated using the Code Digits as input to the Credit-Card checksum 
algorithm. 

OTP - The One-Time-Password. This value is constructed by appending the 
Checksum Digit, if any, to the right of the Code Digits. If there is no 
Checksum Digit, the OTP is the same as the Code Digits. 

One Time Number value is calculated by first shifting in the Hash Bits, and then the 
Synchronization Bits, and then shifting in the result of the check_f unction ( ) of the prior 
intermediate value. 

The binary value is then translated to appropriate character values. There are three likely 
character representations of the password: Decimal, Hexadecimal, and Alpha-Numeric. 



The token can convert the dynamic binary code to decimal and then display then last 
Code Digits plus optionally the checksum. For example, for a six digit, no checksum, decimal 
token will convert the binary code to decimal and display the last six digits. 

Hexadecimal. 

The token can convert the dynamic binary code to hexadecimal and then display then last 
Code Digits plus optionally the checksum. For example, for a six digit, no checksum, 
hexadecimal token will convert the binary code to hexadecimal and display the last six digits. 

Alphanumeric. 

The token can convert the dynamic binary code to base 32 and then display then last 
Code Digits plus optionally the checksum. For example, for a six digit, no checksum, base 32 
token will convert the binary code to base 32 and display the last six digits. 



In order to be a true two-factor authentication token, there can also be a "what you know" 
value in addition to the "what you have" value of the OTP. This value is usually a static PIN or 
password known only to the user. This section discusses three alternative architectures to 
validate this static PIN in accordance with the present invention. 



Required Display Type 
Conversion Cost 
Bits per character 
Keyboard Entry 
Cell Phone Entry 



Decimal Hexadecimal Alpha-Numeric 

7-Segment 7-Segment Alpha-Numeric 
Moderate Trivial Simple 



3.2 4 5 

Simple Easy Easy 
Easy Difficult Difficult 



Decimal. 



The PIN. 
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PIN Validation in the Cloud. 

Enabling PIN validation in the cloud can bind a single PIN to a single token. 
The PIN should be protected over the wire to ensure its not revealed. PIN management (set, 
change) should be implemented by the strong auth service. 

PIN Validation at the Enterprise. 

Enabling PIN validation in the cloud may mean multiple PIN f s for a single token. 
The PIN need never leave the "security world" of the enterprise. PIN management can be 
implemented by the enterprise. 

PIN Validation at the Token. 

This embodiment can be implemented using a keypad on the token. The PIN is never sent 
over the wire, and may be used as a seed to the OTP algorithm. The PIN may be used to simply 
unlock the token. 

Example Data Flows. 

This section describes two data flow scenarios. The first scenario assumes that the 
StrongAuth service does not knows the username associated with a token. In this scenario it is 
assumed that the PIN management operations require the user to enter their token SN, instead of 
their user name. 

The second scenario is very similar to the first, except by the fact that the user name is 
the key into the StrongAuth service, instead of the token SN. There are a few issues in this case. 
First, the username is known to the service, and second we must come up with a scheme to 
ensure a unique mapping from a username to a token SN 

Data Flow#l 
Assumptions: 

• Token SN and S distributed to StrongAuth Service 

• Customer account associated with each token 

• PIN associated with a particular token 

• StrongAuth service saves only the SHA-1 hash of the PIN in the DB 

• Token SN added as an attribute to the user account at the Enterprise, the plugin maps the 
username to the SN. 
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StrongAuth 
Service 



Enterprise 
AuthN 
Server 



Client 



User requests access to a 
protected resource 



I'd like to access A 



Server determines access 
to resource requires AuthN 



AuthN required 



Prompted for usemame 
and password. 
Pushes button on token 
OTP = HMAC-SHA1(S,C) 
Enters usemame 
Enters PIN+OTP 



usemame, PIN+OTP 



Plugin looks up token SN 
based on the usemame 



SN, PIN+OTP 



Validation Server 

* Looks up record from SN 
•Calculates SHA1(PIN) 
and compares local value 

* Calculates 
HMAC-SHA1(S, C) and 
compares with local value. 

* If OTP value matches, 
C=C+1 

* Return "authenticated", 
else return "not 
authenticated" 



authenticated | not authenticated 



Plugin authorizes access 
based on authentication 



Access to resource | authorization denied 



Data Flow #2. 
Assumptions: 

• Token SN and S distributed to StrongAuth Service 

• Customer account and username is associated with each token 

• PEN associated with a particular token 

• StrongAuth service saves only the SHA-1 hash of the PIN in the DB 

• Username is forwarded from enterprise to the Strong Auth service. 
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StrongAuth 
Service 



Enterprise 
AuthN 
Server 



Client 



User requests access to a 
protected resource 



I'd like to access A 



Server determines access 
to resource requires AuthN 



AuthN required 



Prompted for usemame 
and password. 
Pushes button on token 
OTP = HMAOSHA1(S,C) 
Enters usemame 
Enters PIN+OTP 



usemame, PIN+OTP 



Plugin forwards to 
StrongAuth service 



usemame, PIN+OTP 



Validation Server 

* Looks up record from 
usemame 

* Calculates SHA1(PIN) 
and compares local value 

* Calculates 
HMAOSHA1(S,C) and 
compares with local value. 

* If OTP value matches, 
C=C+1 

* Return "authenticated-, 
else return "not 
authenticated" 



authenticated | not authenticated 



Plugin authorizes access 
based on authentication 



Access to resource | authorization denied 
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What is claimed is: 



1 . A method for calculating a One Time Password, comprising: 

concatenting a secret with a count, where the secret is uniquely assigned to a token and is 
shared between the token and an authentication server, and the count is a number that increases 
monotonically at the token with the number of One Time Passwords generated at the token and 
increases monotonically at the authentication server with each calculation of a One Time 
Password at the authentication server; 

calculating HMAC-SHA1 based upon the concatenated secret and count; and 
truncating the result of the HMAC-SHA1 calculation to obtain a One Time Password. 
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